--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Brad,
>  
> Everything is handled on the PC side, all KFLOP knows about is Actuator Space.  I haven't been in that area of code for a long time but it seems like those two functions is all that was needed for our 3Rod test.  BTW in some case you actually only need to specify one function.  For the case of the 3Rod it is easy to go from xyz Cad space to Actuator space (inverse Kinematics) - simply do the geometric correction and then compute the 3 actuator lengths.  To do the forward Kinematics is more difficult so a numerical iterative solution is used.  All it needs to do this is access to the inverse Kinematics.  But in other geometrical arrangements the opposite might be true. 
>  
> The inverse Kinematics are performed more frequently as they are required for each segment.  The forward Kinematics are only needed occasionally to update the DROs fro the Operator and to re-sync after something like a Jog in Actuator Space.
>  
> If you would like to propose some changes to make things more extensible we will most likely include them.  Maybe make the changes and we will consider merging them in.
>  
> Regards
> TK
>  
>  
> From: Brad Murry <bradodarb@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, November 21, 2011 12:38 PM
> Subject: RE: [DynoMotion] Kinematics Function Pointers
>
>
>  
> That is what I was hoping to do(use the two function pointers), I just wanted to run it past you in case I was missing something or if there were any gotcha’s regarding what is run on the pc side vs the board side.
>  
>  
> So for clarity, those are the only two functions I need to provide for coordmotion?  In simplest terms so I do not misunderstand it â€" if I were to inherit from CKinematics and override the two virtual funtions it would just work (actual mat/transforms aside) ?
>  
> No other methods/members except (TransformCADtoActuators and TransformActuatorstoCAD)  of the kinematics class  are called from anywhere?
>  
>   If the above is true, then I am happy to implement it for inclusion to the DynoMotion code base.
>  
>  
> I think that is generally a good idea the way you are allowing contribution, though I have been debating the pros/cons of extensibility vs contribution lately on some other projects I am involved with.
>  
> I was having trouble enforcing code standards in a project and I am leaning towards an extensibility model for that reason.  This way the source is always good, and any functionality the end user extends/adds is kept separated but can be included with the source when applicable.
>  
> Obviously if we were all c++ or all c# we could just inherit from base classes / interfaces etc…
>  
> The only way I have accomplished this in a distributed system(unmanged + .net in this case) is to use interfaces with function pointers.
>  
> Keep in mind that I do not believe what is ideal to me is right for everyone , but “ideally” Coordmotion would have an interface member of something like IKinematics that would hold the two function pointers.  The standard Cartesian class ,the Three Rod class and a generic class(for .net export) could all be implemented from this interface and perhaps passed in via an overloaded contructor.
> Of course, where do you draw the line with the other classes regarding extensibility?  ….
>  
> Again, just offering a different architectural perspective -  end of.  I obviously do like working with the existing code ;)
>  
>  
> -Brad Murry
> From:DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> Sent: Monday, November 21, 2011 12:02 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] Kinematics Function Pointers
>  
>  
> Hi Brad,
>  
> I'm wide open for ideas.  The current scheme (which was just put in for the lack of something better) assumes that various kinematics sub classes would be compiled into the C++ code.  If a User were to develop a new one w would gladly incorporate it into the code.  Currently there is just one (3Rod - 3 linear actuators like a tripod) besides the base class which is simple Cartesian.  The libraries at run-time look for a Kinematics.txt file in the Data directory to decide which type of Kinematics class to instantiate as well as possibly some initialization parameters (joint positions and whatnot specific to that subclass). 
>  
> I have no problem modifying or abandoning that scheme - if you can demonstrate something better :}
>  
> It seems as what you are describing could be accomplished by just registering two callbacks for those two functions.
>  
> Regards
> TK   
>  
> From:bradodarb <bradodarb@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, November 21, 2011 8:52 AM
> Subject: [DynoMotion] Kinematics Function Pointers
>  
> Hello Tom,
>
> One of the things I would like to add in at some point is the option for custom kinematics via .net classes.
>
> At this point my ambitions go no further than to implement a SCARA type arm, but it would just be way cool to have that side of things opened a little.
>
> Obviously I could easily override CKinematics and do it there but I would then be dealing with a customized source that would be out of sync with your updates.
>
> Could I just create a custom kinematics derived class that uses function pointers for ::
>
> virtual int TransformCADtoActuators(double x, double y, double z, double a, double b, double c, double *Acts);
>
> AND
> virtual int TransformActuatorstoCAD(double *Acts, double *x, double *y, double *z, double *a, double *b, double *c);
>
> ?
>
> I think I could just add an exported function to dotNetInterop to set Coordmotion's kinematics to the cutom class and pass in two function pointers(which would be delgates on the .net side).
>
> What are your thoughts?
>
> -Brad Murry
>  
>